Knowledge Overview

BindAI Knowledge provides the abstractions and execution components needed to connect agents with external information. The Knowledge system supports document ingestion, loading, parsing, chunking, embeddings, metadata, retrieval, reranking, conversational retrieval, and knowledge pipelines. Knowledge can also be integrated with agents so that relevant external information can be retrieved and supplied as context during agent execution.

What is Knowledge?

Knowledge provides a structured way to make external information available to an AI application. Examples include:

Application documentation
Business information
Product documentation
Reference material
Text documents
Knowledge bases
Other application-specific information

A typical Knowledge workflow looks like:

External Information
        |
        v
     Loading
        |
        v
     Parsing
        |
        v
     Chunking
        |
        v
    Embeddings
        |
        v
     Indexing
        |
        v
     Retrieval
        |
        v
      Agent
        |
        v
      Model

The individual stages can be configured according to the application’s requirements.

Knowledge and RAG

Knowledge is closely related to Retrieval-Augmented Generation (RAG). RAG combines external information retrieval with language-model generation. A typical flow is:

User Question
      |
      v
Knowledge Retrieval
      |
      v
Relevant Information
      |
      v
Model Context
      |
      v
Language Model
      |
      v
Response

BindAI provides components for implementing this pattern rather than requiring applications to build the entire retrieval pipeline themselves.

Knowledge vs Memory

Knowledge and Memory serve different purposes.

Knowledge	Memory
External or reference information	Application and agent memory
Designed for retrieval	Stores `MemoryRecord` objects
Commonly organized as documents/chunks	Organized using keys, values, namespaces, and metadata
Used to provide relevant external context	Used to retain application-specific information
Supports retrieval and RAG workflows	Supports memory persistence and lifecycle management

For example, a company’s product manual is a good candidate for Knowledge. A user’s preferred programming language is more naturally represented as Memory. Applications can use both systems together.

Knowledge vs Tools

Knowledge and tools also solve different problems. A tool is executable application logic. For example:

from bindai import tool


@tool
def get_customer_status(customer_id: str) -> str: ...

A tool can call an API, execute business logic, query a database, or perform another operation. Knowledge is intended for information retrieval. A simplified distinction is:

Tool
 |
 +-- Execute an operation
 |
 +-- Call an external service
 |
 +-- Perform application logic


Knowledge
 |
 +-- Store/index information
 |
 +-- Retrieve relevant information
 |
 +-- Supply external context

Applications can use tools and Knowledge together.

Knowledge Pipeline

Knowledge processing can be viewed as a pipeline:

Source
  |
  v
Loader
  |
  v
Document
  |
  v
Parser
  |
  v
Chunks
  |
  v
Embeddings
  |
  v
Index / Retrieval Store
  |
  v
Retriever
  |
  v
Relevant Results

Each stage has a specific responsibility. This separation allows applications to replace or configure individual stages without changing the overall Knowledge architecture.

Documents

Knowledge operates on document-oriented information. A document can originate from an application-supported source and then be transformed into smaller searchable units. The general processing flow is:

Document
   |
   v
Parse Content
   |
   v
Split into Chunks
   |
   v
Attach Metadata
   |
   v
Generate Embeddings
   |
   v
Store for Retrieval

Documents and chunks can carry metadata that helps applications organize and filter retrieved information.

Loading and Ingestion

Knowledge supports document loading and ingestion workflows. A typical ingestion process is:

Input Source
     |
     v
Document Loader
     |
     v
Document Processing
     |
     v
Chunking
     |
     v
Embedding
     |
     v
Knowledge Store

The ingestion pipeline separates acquiring source content from preparing it for retrieval. This makes it possible to build repeatable knowledge-ingestion workflows rather than manually preparing every document.

Chunking

Large documents are commonly divided into smaller chunks before indexing. For example:

Large Document
      |
      v
+-------------+
| Chunk 1     |
+-------------+
| Chunk 2     |
+-------------+
| Chunk 3     |
+-------------+
| Chunk 4     |
+-------------+

Chunking improves retrieval by allowing the system to identify relevant portions of a document rather than retrieving an entire document for every query. Chunking strategy should be selected according to the structure and content of the source material.

Embeddings

Embeddings represent text as numerical vectors. Conceptually:

Text
 |
 v
Embedding Model
 |
 v
Vector

The resulting vectors can be compared to identify semantically related information. BindAI provides an embedding abstraction that allows knowledge and retrieval components to work with embedding providers without coupling the application to one embedding implementation. OpenAI embeddings are currently supported, along with the framework’s local/deterministic embedding implementation used for development and testing.

Retrieval

Retrieval selects information relevant to a query. A simplified retrieval flow is:

Query
  |
  v
Retriever
  |
  +----> Candidate Results
  |
  v
Ranked Results

BindAI supports multiple retrieval approaches, including:

Vector retrieval
BM25 retrieval
Hybrid retrieval
Metadata filtering
Reranking

The appropriate strategy depends on the type of knowledge and the application’s requirements.

Vector Retrieval

Vector retrieval uses embeddings to identify semantically related information. For example:

Query:
"How can I regain access to my account?"

        |
        v

Embedding Similarity

        |
        v

Document:
"Credential recovery procedure"

The wording does not need to match exactly for the information to be considered relevant. Vector retrieval is particularly useful when semantic similarity is more important than exact keyword matching.

BM25 Retrieval

BM25 provides lexical retrieval based on term matching and relevance scoring. It is useful when the exact words in a query are important. For example:

Query:
"PostgreSQL connection timeout"

        |
        v

BM25

        |
        v

Documents containing relevant terms

BM25 can be useful on its own or as part of a hybrid retrieval strategy.

Hybrid Retrieval

Hybrid retrieval combines different retrieval signals. A conceptual flow is:

                 Query
                   |
          +--------+--------+
          |                 |
          v                 v
      BM25 Search      Vector Search
          |                 |
          +--------+--------+
                   |
                   v
             Combined Results
                   |
                   v
                Reranker
                   |
                   v
             Final Results

Hybrid retrieval can improve robustness when both exact terminology and semantic similarity are important.

Metadata

Knowledge records can carry metadata describing the source or content. Examples include:

source
document
category
author
date
section
tenant

Metadata can be used to organize, filter, and interpret retrieval results. For example, an application may restrict retrieval to documents belonging to a particular category or tenant. Metadata design should be consistent across the application’s ingestion and retrieval pipeline.

Filtering

Knowledge retrieval can use metadata filtering to narrow the candidate information. Conceptually:

Query
  |
  v
Metadata Filter
  |
  v
Candidate Documents
  |
  v
Retrieval
  |
  v
Relevant Results

Filtering is particularly useful for multi-tenant systems, document categories, access scopes, or other application-defined boundaries. Filtering behavior depends on the configured retrieval and storage implementation.

Reranking

Initial retrieval can produce a set of candidate results. Reranking can then reorder those results according to a more focused relevance strategy.

Query
  |
  v
Initial Retrieval
  |
  v
Candidate Results
  |
  v
Reranker
  |
  v
Improved Result Ordering

BindAI provides a reranker abstraction and a lexical reranking implementation. Reranking can be combined with vector, BM25, or hybrid retrieval.

Conversational Retrieval

Knowledge retrieval can also be used in conversational applications. A conversational retrieval flow can use previous conversation context when interpreting a new query.

Conversation
     |
     v
Current Question
     |
     v
Query Interpretation
     |
     v
Knowledge Retrieval
     |
     v
Relevant Context
     |
     v
Agent / Model

This is useful when a user’s current question depends on information established earlier in the conversation. Conversational retrieval remains distinct from conversation Memory: retrieval provides external knowledge, while Memory stores application-specific retained information.

Knowledge Pipelines

BindAI provides knowledge pipeline components for organizing ingestion and retrieval-related processing. A pipeline can coordinate stages such as:

Load
 |
 v
Parse
 |
 v
Chunk
 |
 v
Embed
 |
 v
Store

Retrieval can then operate over the processed knowledge:

Query
 |
 v
Retrieve
 |
 v
Filter
 |
 v
Rerank
 |
 v
Context

Pipelines provide a structured way to organize these operations rather than placing all knowledge-processing logic directly in application code.

Knowledge and Agents

Knowledge can be integrated with agents through the agent’s Knowledge configuration. A simplified architecture is:

User Input
    |
    v
Agent
    |
    v
Knowledge
    |
    v
Retriever
    |
    v
Relevant Context
    |
    v
Model Request
    |
    v
Agent Response

This allows an agent to use external information while keeping the Knowledge implementation separate from the model provider. The agent can also use Memory, tools, and other execution capabilities alongside Knowledge.

Knowledge, Memory, and Tools Together

A production agent may combine all three systems.

                    Agent
                      |
        +-------------+-------------+
        |             |             |
        v             v             v
     Memory       Knowledge       Tools
        |             |             |
        v             v             v
 User/Application   External      Actions
     Context        Information   / Services

For example:

Memory can provide a user’s stored preferences.
Knowledge can provide relevant product documentation.
A tool can call an external API to retrieve live information.

Each system has a different responsibility.

Knowledge and Workflows

Knowledge can also participate in workflows. A workflow may perform ingestion:

Workflow
   |
   v
Load Documents
   |
   v
Process Documents
   |
   v
Chunk
   |
   v
Embed
   |
   v
Store

Another workflow can perform retrieval:

Workflow
   |
   v
Receive Query
   |
   v
Retrieve Knowledge
   |
   v
Filter / Rerank
   |
   v
Pass Context to Agent

This allows Knowledge operations to become part of larger application automation.

Knowledge Sources

Knowledge systems can be built from many kinds of external information. Depending on the configured loaders and integrations, applications may work with sources such as:

Text documents
Markdown
Application-generated content
Structured records
External data sources

The supported source types should be determined by the installed loader and integration implementations. Applications should not assume that every possible file or external service is automatically supported.

Knowledge Providers and Retrieval Components

Knowledge is composed of multiple abstractions rather than a single storage implementation. The current implementation includes components for:

Documents
Loaders
Parsing
Chunking
Embeddings
Metadata
Retrieval
Search options
Reranking
Conversational retrieval
Knowledge pipelines

This modular design allows different parts of the Knowledge system to evolve independently.

Search Options

Knowledge retrieval can be configured according to application requirements. Relevant retrieval choices include:

Vector search
BM25 search
Hybrid search
Metadata filtering
Result limits
Reranking
Conversational query handling

Applications should select retrieval settings based on the type of information being searched and the expected query patterns.

Knowledge Quality

Retrieval quality depends on more than the language model. Important factors include:

Source Quality
     |
     v
Parsing Quality
     |
     v
Chunking Strategy
     |
     v
Embedding Quality
     |
     v
Retrieval Strategy
     |
     v
Filtering
     |
     v
Reranking
     |
     v
Final Context
     |
     v
Model Response

Poorly structured documents or inappropriate chunking can reduce retrieval quality even when the model itself is capable of producing strong responses. Knowledge pipelines should therefore be tested using representative documents and queries.

Knowledge Security

Knowledge systems can contain private or sensitive information. Applications should consider:

Tenant isolation
Access control
Metadata filtering
Source permissions
Secure storage
Credential management
Data retention
Document deletion

Metadata filtering can help implement logical retrieval boundaries, but filtering should not be treated as the application’s only authorization mechanism. Authorization should be enforced at the application level.

Current Knowledge Capabilities

The current BindAI Knowledge implementation includes:

Document abstractions
Document loading
Ingestion pipelines
Parsing
Chunking
Metadata
Embedding abstractions
OpenAI embeddings
Local/deterministic embeddings
Vector retrieval
BM25 retrieval
Hybrid retrieval
Search configuration
Metadata filtering
Reranking
Lexical reranking
Conversational retrieval
Knowledge pipelines
Agent Knowledge integration

These components provide the foundation for building retrieval-augmented AI applications.

Knowledge and Production RAG

A production RAG system commonly combines several Knowledge components:

                 Documents
                     |
                     v
                 Ingestion
                     |
        +------------+------------+
        |                         |
        v                         v
     Chunking                 Metadata
        |                         |
        v                         |
    Embeddings                    |
        |                         |
        +------------+------------+
                     |
                     v
                Knowledge Store
                     |
                     v
                   Query
                     |
          +----------+----------+
          |                     |
          v                     v
       BM25 Search        Vector Search
          |                     |
          +----------+----------+
                     |
                     v
                  Hybrid
                     |
                     v
                 Filtering
                     |
                     v
                 Reranking
                     |
                     v
              Relevant Context
                     |
                     v
                   Agent
                     |
                     v
                  Model

Not every application needs every stage. A simple application may only require vector retrieval, while a more advanced application may combine lexical retrieval, vector retrieval, filtering, and reranking.

Best Practices

Keep Knowledge separate from Memory and tools.
Use Knowledge for external or reference information.
Use Memory for application-specific retained information.
Use tools for executable actions and live external operations.
Choose chunking strategies appropriate to the source documents.
Use metadata consistently during ingestion and retrieval.
Select retrieval strategies based on query characteristics.
Use hybrid retrieval when both lexical and semantic signals are valuable.
Use reranking when initial retrieval produces too many similar candidates.
Test retrieval quality with realistic queries.
Keep tenant and access boundaries explicit.
Do not treat metadata filtering as a complete authorization system.
Keep provider-specific behavior documented separately from the general Knowledge abstraction.
Avoid indexing unnecessary sensitive information.
Keep embedding dimensions compatible with the configured vector storage.
Treat ingestion and retrieval as separate concerns where appropriate.

Summary

BindAI Knowledge provides a modular foundation for connecting agents with external information. The main architecture is:

Documents
    |
    v
Loading / Ingestion
    |
    v
Parsing / Chunking
    |
    v
Embeddings
    |
    v
Knowledge Storage
    |
    v
Retrieval
    |
    +---- BM25
    |
    +---- Vector
    |
    +---- Hybrid
    |
    v
Filtering / Reranking
    |
    v
Relevant Context
    |
    v
Agent
    |
    v
Model

The current implementation includes document ingestion, chunking, embeddings, metadata, vector retrieval, BM25, hybrid retrieval, filtering, reranking, conversational retrieval, knowledge pipelines, and agent integration. Knowledge is therefore a concrete part of the current BindAI architecture rather than only a future roadmap concept. It works alongside Memory, tools, workflows, and model providers to provide the external-information layer required by retrieval-augmented AI applications.

​Knowledge Overview

​What is Knowledge?

​Knowledge and RAG

​Knowledge vs Memory

​Knowledge vs Tools

​Knowledge Pipeline

​Documents

​Loading and Ingestion

​Chunking

​Embeddings

​Retrieval

​Vector Retrieval

​BM25 Retrieval

​Hybrid Retrieval

​Metadata

​Filtering

​Reranking

​Conversational Retrieval

​Knowledge Pipelines

​Knowledge and Agents

​Knowledge, Memory, and Tools Together

​Knowledge and Workflows

​Knowledge Sources

​Knowledge Providers and Retrieval Components

​Search Options

​Knowledge Quality

​Knowledge Security

​Current Knowledge Capabilities

​Knowledge and Production RAG

​Best Practices

​Summary